今天來進一步探討更細節的幾個問題
像是XDES Entry結構到底儲存在表格空間的那邊?
直屬於表格空間的鏈結串列基節點儲存在表格空間那邊?
每個段對應的INODE Entry結構儲存在表格空間那邊?
為此我們需要更進一步了解前面提到的一些分組前面的固定頁面
FSP_HDR類型。
我們知道這頁用來登記整個表格空間的一些整體屬性及本組所有區的屬性。
其實XDES Entry結構就是儲存在這裡。
這頁包含了
這裡File Header、File Trailer不特別強調,Empty Space這也不用管它
我們看兩個重要的屬性就好
第一個File Space Header
第二個XDES Entry
再來XDES Entry的部分,由於一個XDES Entry結構的大小是40位元組,由於一個頁面的大小有限,只能存放一定數量的XDES Entry結構,所以才把256個區畫成1組,每組的第一頁存放256個XDES Entry結構。
所以我們前面的問題都有了答案
像是XDES Entry結構到底儲存在表格空間的那邊?
直屬於表格空間的鏈結串列基節點儲存在表格空間那邊?
每個段對應的INODE Entry結構儲存在表格空間那邊?
都是存在每組最開始的第一頁
XDES類型
大家還記得其餘各組最開始二頁的類型是固定的,第一頁是XDES頁,用來登記本組256個區的屬性。基本上它的內容跟FSP_HDR幾乎一樣,差別只在於XDES沒有File Space Header(紀錄表格空間的一些整體屬性資訊)。
IBUF_BITMAP類型
所有組別的第二頁都是IBUF_BITMAP頁,用來儲存關於Change Buffer的一些資料。
我們在表中插入一筆紀錄,本質上是向每個索引對應的B+樹插入紀錄。該紀錄先插入聚簇索引頁面,然後再插入每個二級索引頁面。這些頁面在表格空間中隨機分佈(雖然有雙向鏈結串列串在一起,但物理記憶體上是不連續的,所以磁碟需要重新定位),也產生大量的隨機I/O,嚴重影響性能。所以引入了Change Buffer結構(本質上也是表格空間中的一顆B+樹,它的根節點儲存在系統表格空間中)。在修改非唯一二級索引頁面時,如果該頁尚未被載入到記憶體中(仍在磁碟),那麼該修改先暫時快取到Change Buffer,等其需要載入到記憶體,才將修改合併到對應頁面。(以前只會快取Insert操作,所以Change Buffer以前被稱為Insert Buffer[IBUF],但現在Update跟Delete也會快取)
INODE類型
第一組的第三頁是INODE,顧名思義就是為了儲存INODE Entry結構而存在的,也就是說跟第一頁有些類似。內容如下:
這頁包含了